Hi all, strange issue here. I have some users that used to send mails using the "from:" field in Outlook. The second mail adress they are using is associated with a distribution list where they were givn the "send as" right. Some days ago my users started to get error messages saying "you do not have permission to send to this recipient. Contact your system administrator". I had them send mails using the from:-field to my company address and even internally they got this error message. I then created a second distribution group, granted myself and my users the "send as" right and on the second DL there´s the same problem: "you do not have permission to send to this recipient. Contact your system administrator". My users are using Outlook 2003 and 2007 clients, I am using Outlook 2010. I think I can exclude DNS or firewall issues, because the error is even sending from one domain user to another. Has anyone an idea what this could be? I already applied this hotfix: http://support.microsoft.com/kb/895949 Cheers Thomas

On Wed, 13 Oct 2010 10:27:31 +0000, Trommeltier24 wrote: >strange issue here. I have some users that used to send mails using the "from:" field in Outlook. The second mail adress they are using is associated with a distribution list where they were givn the "send as" right. Some days ago my users started to get error messages saying "you do not have permission to send to this recipient. Contact your system administrator". I had them send mails using the from:-field to my company address and even internally they got this error message. > >I then created a second distribution group, granted myself and my users the "send as" right and on the second DL theres the same problem: "you do not have permission to send to this recipient. Contact your system administrator". My users are using Outlook 2003 and 2007 clients, I am using Outlook 2010. > >I think I can exclude DNS or firewall issues, because the error is even sending from one domain user to another. > >Has anyone an idea what this could be? Well, the error message says you don't have permission to send *TO* the recipient. The "Send As" permission shouldn't be the issue. What's changed in your AD? Have you blocked inheritence of permissions? Do you have restrictions on who can send to anyone? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

No changes on the AD. No inheritance blocked and no deny´s set on the ACL for the specific users where this happens. But even if I set the "send to" right doesn´t change anything.

Try telnetting to the person. If it is blocked you have permissions issue . Try checking it from Raw AD data using adsiedit ( not recommneded though) . If you have already assigned permissions and waiting for results initiate AD replication , disgnostic logging etc

On Thu, 14 Oct 2010 07:30:33 +0000, Trommeltier24 wrote: >No changes on the AD. No inheritance blocked and no denys set on the ACL for the specific users where this happens. But even if I set the "send to" right doesnt change anything. In your original post you said "even internally they got this error message". Does this mean that you're NOT using Outlook with a MAPI/RPC or RPC-Over-HTTPS connection, or OWA? Are you sure that the "only from authenticated users" restriction isn't checked on this DL? Do the senders get a NDR? If they do, please post the contents. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I had a user getting this error when sending to a single address. It was quite puzzling as the user could send to other addresses in the same namespace. It turned out that the address itself was the problem. The user had copied and pasted it out of another email, and even though it looked correct, the "Email type:" property was altered from "SMTP" to "MAILTO". Not sure why that would matter, but making sure the type was SMTP solved it. You can access the properties by right clicking on the address in the To: box. Hope that helps, Chris

I am getting this same error for a couple of users, it started happening in just the past couple of days (Exchange 2003, single mailbox server, single AD domain). Exact same error as reported here, this is what the NDR looks like (changed users name, domainname, and server netbios name): Subject: Undeliverable: FW: Information Your message did not reach some or all of the intended recipients. Subject: FW: Information Sent: 10/28/2010 12:53 PM The following recipient(s) cannot be reached: Doe, Jane on 10/28/2010 12:53 PM You do not have permission to send to this recipient. For assistance, contact your system administrator. MSEXCH:MSExchangeIS:/DC=CA/DC=DomainName:ServerName That example was simply one user sending to another domain user from Outlook (cached mode). Problem seems intermittent, not always there for the few that have reported it. For one, it got better for 2 days and is now back again. Message tracking, SMTP, NDR logging on high reveals nothing useful. One user says it happens when sending from a shared mailbox account. The user with the NDR above sends normally and without sending as someone else. We did MS patches on the weekend (Sunday) and the first reports were a day or two after that. Trommeltier24, was your Exchange server patched recently? I started another thread on this, but as this seems to be a common problem I though I would post here too.

On Thu, 28 Oct 2010 21:53:16 +0000, eChange wrote: [ snip ] > You do not have permission to send to this recipient. For assistance, contact your system administrator. > > MSEXCH:MSExchangeIS:/DC=CA/DC=DomainName:ServerName If the IS is telling you that you don't have permission to send to the user then check the delivery restrictions on that user. >That example was simply one user sending to another domain user from Outlook (cached mode). Problem seems intermittent, not always there for the few that have reported it. For one, it got better for 2 days and is now back again. Message tracking, SMTP, NDR logging on high reveals nothing useful. One user says it happens when sending from a shared mailbox account. Does the shared mailbox have permission to send to the other mailbox? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi, Where do I check delivery restrictions for the user? I have verified the user has send as permissions to the mailbox. As of yesterday, the user experienced the error multiple times between 9 am and around noon, and sending as the shared mailbox has worked fine since then. I checked the other user that reported the issue (no shared mailbox involved, just her own account), she had the problem twice today to 2 internal users. message tracking logs see the report sent to the user for the NDR, NDR logging to max doesnt show anything. I re-sent the message again from her computer and account, and it went through (message tracking shows successful delivery to the recipient). Its the intermittent part of this issue that has me perplexed. I checked our DCs, nothing obviously wrong in the event logs for them. The one commonality I can find is that both users were upgraded from Office 2003 to 2007 about two weeks ago (but so were hundreds of others that are not having issues). The

On Fri, 29 Oct 2010 16:33:21 +0000, eChange wrote: >Where do I check delivery restrictions for the user? ADUC. On the "Exchange General" tab of the user's property page. >I have verified the user has send as permissions to the mailbox. As of yesterday, the user experienced the error multiple times between 9 am and around noon, and sending as the shared mailbox has worked fine since then. If it doesn't happen all the time then either it's not a problem with the delivery restrictions or someone's screwing with you. >I checked the other user that reported the issue (no shared mailbox involved, just her own account), she had the problem twice today to 2 internal users. message tracking logs see the report sent to the user for the NDR, NDR logging to max doesnt show anything. I re-sent the message again from her computer and account, and it went through (message tracking shows successful delivery to the recipient). > >Its the intermittent part of this issue that has me perplexed. I checked our DCs, nothing obviously wrong in the event logs for them. > >The one commonality I can find is that both users were upgraded from Office 2003 to 2007 about two weeks ago (but so were hundreds of others that are not having issues). Are they working in cached-mode or on-line mode? Does the symptom change when they change modes? Have you installed SP2 for MS Office 2007? Any rollups? What do you see for build numbers in the "Help | About" menu for Outlook? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I have checked, there are no delivery restrictions to either mailbox. Both users are using cached mode. One is a desktop user, I have switched her to on-line mode to see if there are any changes. Although she has not reported the error since early this morning (and my re-send to the same recipient from her outlook worked anyway a couple of hours after she got the error). Both users were upgraded to 2007 from the same automated installation files. Windows auto updates are on and all updates available have been applied. The fist user (who had issues with the send as stuff) has reported back his version: Microsoft Office Outlook 2007 (12.0.6539.5000) SP2 MSO (12.0.6535.5002) I am waiting on the 2nd user for that info.

Hmm. This is getting indeed stranger by the moment. The 2nd user from time to time also uses a shared mailbox and uses send as for it (she changes the From field to the shared mailboxes name). Now, she tries to send as by changing the from field (the mailbox is loaded as an additional mailbox in her outlook profile) and gets a window stating that she does not have permission to send as the mailbox. I have checked under the mailbox rights of the shared mailbox (Exchange advancedm mailbox rights) and she is set to full permissions. Under the actual shared mailbox account's security tab, I dont see her listed at all (just see the standard inherited permissions for exchange enterprise servers, blackberry server account, etc). This was working for her earlier this week, she sends as the shared mailbox once every couple of days on average. I am now pulling my hair out. Soooo .... (deep breath) Send As needs to be set for her on the shared mailboxes security tab. She still has full mailbox permissions under mailbox rights. I have added her with send as permission to the accounts security options. I will now wait a couple of hours for the change to propagate (probably she will be gone home and I will follow up on Monday again) Any further input is appreciated.

On Fri, 29 Oct 2010 21:08:31 +0000, eChange wrote: > > >Hmm. This is getting indeed stranger by the moment. The 2nd user from time to time also uses a shared mailbox and uses send as for it (she changes the From field to the shared mailboxes name). Now, she tries to send as by changing the from field (the mailbox is loaded as an additional mailbox in her outlook profile) and gets a window stating that she does not have permission to send as the mailbox. I have checked under the mailbox rights of the shared mailbox (Exchange advancedm mailbox rights) and she is set to full permissions. Under the actual shared mailbox account's security tab, I dont see her listed at all (just see the standard inherited permissions for exchange enterprise servers, blackberry server account, etc). > >This was working for her earlier this week, she sends as the shared mailbox once every couple of days on average. I am now pulling my hair out. > > > >Soooo .... (deep breath) > >Send As needs to be set for her on the shared mailboxes security tab. She still has full mailbox permissions under mailbox rights. > >I have added her with send as permission to the accounts security options. I will now wait a couple of hours for the change to propagate (probably she will be gone home and I will follow up on Monday again) > >Any further input is appreciated. Well, the "Send As" permission on the user (not the mailbox) has been necessary for several years (assigning FMA *used* to give that permission, but no longer). So, are you saying that "Send As" was there and now it's gone? If you assign "Send As" on the shared mailbox does it disappear after an hour or so? If it does, see if that user has an "adminCount" property value of something other than zero. Maybe someone made the shared mailbox a member of a group that's protected. Search for "adminSDHolder" and you'll find the groups that are protected and explanations of how permissions seem to disppear by themselves. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Fri, 29 Oct 2010 19:35:18 +0000, eChange wrote: >I have checked, there are no delivery restrictions to either mailbox. I suspected as much. Still, it's the Information Store (MSEXCH:MSExchangeIS:/DC=CA/DC=DomainName:ServerName) that's claiming the sender has insufficient permissions. If they're in cached-mode the missing permission could be "Send As" or "Send on Behalf Of" on some other mailbox. >Both users are using cached mode. One is a desktop user, I have switched her to on-line mode to see if there are any changes. Although she has not reported the error since early this morning (and my re-send to the same recipient from her outlook worked anyway a couple of hours after she got the error). > >Both users were upgraded to 2007 from the same automated installation files. Windows auto updates are on and all updates available have been applied. > >The fist user (who had issues with the send as stuff) has reported back his version: > >Microsoft Office Outlook 2007 (12.0.6539.5000) SP2 MSO (12.0.6535.5002) That's pretty current (June 29, 2010). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Well, Monday morning and now theres another 4 users with the same problem. It actually seems to be 2 problems: some send from a shared mailbox and get the bounce. Others send from their own accounts and get the bounce. So, for the first new ticket this morning, user gets bounce when sending from a shared mailbox. I have looked in AD at the shared mboxes attributes. In ADUC, Exchange Advanced/Mailbox Rights, I see the user has: delete mailbox storage, Read permissions and Full mailbox access permissions. In Exchange General\Delivery Options, no one is listed under Send on Behalf. In the security tab of the shared mbox account, the user is not listed. She is not in today, but to test things I have added her with Send As permission to the account. I will follow up with her tomorrow to see if that has helped. These bounces, so far, regardless of whether sending from their own or a shared mailbox, seem to be happening for users that access shared mailboxes in some way (and have a shared mailbox open in addition to their own, in Outlook). I dont know how things could possibly have been working before if she didnt have send as or send on behalf permissions. I assume that if the delegation was done in Outlook's settings (if connecting to the shared mailbox in Outlook), those would be reflected in the AD user delivery options send on behalf list? And any delegated permissions to the shared mailbox would show in Mailbox Rights? Edit - clarified the situation with one user. It doesnt happen when sending as herself - the misunderstanding was that she is replying to a message in the shared mailbox, so of course what really is happening is a 'Send As' the shared mailbox. I checked her perms, and its the same as described above ... full mbox rights, no send on behalf listed in AD, no Send As under security. Added her for Send As. It will take 2 hours for the change to take effect, will follow up after that.

On Mon, 1 Nov 2010 17:07:01 +0000, eChange wrote: [ snip ] >Edit - clarified the situation with one user. It doesnt happen when sending as herself - the misunderstanding was that she is replying to a message in the shared mailbox, so of course what really is happening is a 'Send As' the shared mailbox. I checked her perms, and its the same as described above ... full mbox rights, no send on behalf listed in AD, no Send As under security. Added her for Send As. It will take 2 hours for the change to take effect, will follow up after that. What about the adminCount property I asked about in another answer to another of your posts? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

>> What about the adminCount property I asked about in another answer to >> another of your posts? OK, so I have checked things. Not looking good. ldifde export shows virtually every user in the domain (400+) as admincount of 1. Since this is a 2003 AD, I have checked the following protected groups for any nested groups, etc: Administrators,Account Operators,Server Operators,Print Operators,Backup Operators,Domain Admins,Schema Admins,Enterprise Admins,Cert Publishers The members and groups within those look OK, membership restricted to various tech staff. I checked the output of ldifde for any groups that have admincount=1, there are only a couple that are used for system admin type stuff (with correct membership limited to a few admins), however there is one group that does seem to contain every domain user (it seems to be used for an access to an important accounting/admin/calendaring application used by many users). I have checked this group's members, and they are all domain users, no groups listed as members. From what I have read, if I add someone to Send As permissions and they have admincount=1, the permission should be removed after about 1 hour. I set Send As permissions for a couple of users on Friday, and they are still set today (and no reports of further issues). Some users I set the permission for yesterday are still set as well. So, I am at a loss to explain why this one group containing everyone has admincount=1, or why Send As permissions have not been removed yet.

On Tue, 2 Nov 2010 17:21:24 +0000, eChange wrote: >>> What about the adminCount property I asked about in another answer to >> another of your posts? OK, so I have checked things. Not looking good. ldifde export shows virtually every user in the domain (400+) as admincount of 1. Since this is a 2003 AD, I have checked the following protected groups for any nested groups, etc: Administrators,Account Operators,Server Operators,Print Operators,Backup Operators,Domain Admins,Schema Admins,Enterprise Admins,Cert Publishers The members and groups within those look OK, membership restricted to various tech staff. I checked the output of ldifde for any groups that have admincount=1, there are only a couple that are used for system admin type stuff (with correct membership limited to a few admins), however there is one group that does seem to contain every domain user (it seems to be used for an access to an important accounting/admin/calendaring application used by many users). I have checked this group's members, and they are all domain >users, no groups listed as members. From what I have read, if I add someone to Send As permissions and they have admincount=1, the permission should be removed after about 1 hour. I set Send As permissions for a couple of users on Friday, and they are still set today (and no reports of further issues). Some users I set the permission for yesterday are still set as well. So, I am at a loss to explain why this one group containing everyone has admincount=1, or why Send As permissions have not been removed yet. The adminCount property is not set to zero (or removed from the user's AD object) when/if they're removed from a protected group. Sorting out who should have adminCount set to a value greater than 0 can be a chore. For those users that you think (or know) are not in any protected group (or in a group that's a member of a protected group), go ahead and remove the adminCount property. If, after a couple of hours, it hasn't reappeared then the user is no longer a member of a protected group. If the adminCount property reappears, or the value is changed from 0 to 1 then they're still a member of a protected group and you'll have to figure out how they came to be a member of a protected group (and which group it is). It's a good practice the keep "normal" users out of protected groups and give them "administrator" accounts to do the work that requires the special privileges that lead to the adminSDHolder problems. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I have checked this morning after clearing one users admincount yesterday (I guess that sets it to null).It is still set to null. I did notice in adsidedit that looking at the security tab shows that the inherit permissions check box is unchecked. I looked at a few others and this is also the case. So this should mean that any Send as permissions I grant a shared mailbox should stick and not get reset, right? So far, the Send As permissions havent been cleared. Although I should test with a server reboot at some point I think (much of the current grief seemed to start after server was patched and rebooted Oct 24th). I do wonder about the one non-protected group that has admincount=1. It contains every employee's account. Would being in that group be whats setting everyone's admincount=1 as well? There are no nested groups inside it nor is that group a member of any other groups. I wonder if it would be prudent to set the group's admincount to 0 or clear it. I will check to see if there are any distribution groups with admincount=1 as well.

On Wed, 3 Nov 2010 16:53:53 +0000, eChange wrote: >I have checked this morning after clearing one users admincount yesterday (I guess that sets it to null).It is still set to null. I did notice in adsidedit that looking at the security tab shows that the inherit permissions check box is unchecked. Allow inheritence. That's another aspect of those users once having been in a protected group. >I looked at a few others and this is also the case. So this should mean that any Send as permissions I grant a shared mailbox should stick and not get reset, right? It does, but it also means that the users aren't inheriting the permission they should be to allow Exchange to work properly with their mailboxes. >So far, the Send As permissions havent been cleared. Although I should test with a server reboot at some point I think (much of the current grief seemed to start after server was patched and rebooted Oct 24th). Rebooting the server won't change anything. >I do wonder about the one non-protected group that has admincount=1. It contains every employee's account. Would being in that group be whats setting everyone's admincount=1 as well? That depends on whether or not the security group is a member of some protected group. If it isn't then it won't. But you should clear that adminCount property and enable permission inheritence on the group if it's not a member of some protected group. >There are no nested groups inside it nor is that group a member of any other groups. I wonder if it would be prudent to set the group's admincount to 0 or clear it. See above. >I will check to see if there are any distribution groups with admincount=1 as well. That's unlikely since DLs aren't security principles. From the way you describe this, I'd guess that someone made that group a member of a protected group at some time in the past. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Today, I had a report that the issue came back for a user. I checked, and the shared mailbox account's permissions have reverted back to their default (the Send As permssions are gone). So, it seems to last a few days at most before being reset. I have changed the mailboxes admincount to null for now and re-added the permissions. Looking at inheritance, it is unchecked. With a test account, if I allow inheritance, a whole bunch of new permissions are applied and some existing ones removed, so I am unsure what the effect would be on users at the moment. I dont know why the permissions are reset after such a long time, I thought by default they would be re-applied after 1 hour or so. I did check to see if the reg key that can change the default time is set, and it is not preset. Man, I hate inheriting an Exchange structure that is a mish-mash of several external people's changes/upgrades/hacks done over a few years. So, for now if I clear admincount but leave inheritance as is (no inheritance), will the permissions still be reset at some future date I wonder? I need time to assess whether enabling inheritance will break even more stuff.

On Mon, 8 Nov 2010 22:30:53 +0000, eChange wrote: >Today, I had a report that the issue came back for a user. I checked, and the shared mailbox account's permissions have reverted back to their default (the Send As permssions are gone). Was this an account from which you removed the adminCount property? Is the adminCount property back, and is its value greater than zero? If so, what's the value in the whenModified property? >So, it seems to last a few days at most before being reset. I have changed the mailboxes admincount to null for now and re-added the permissions. So adminCount wasn't there before (or the value was zero)? It sounds like something (or someone) is giving the account membership in some privileged group and then removing it from the group -- maybe as a "favor" so they can do something they think they should be doing but don't ordinarily have permission to do. >Looking at inheritance, it is unchecked. That's normal if the accounhas a adminCount greater than zero. >With a test account, if I allow inheritance, a whole bunch of new permissions are applied and some existing ones removed, so I am unsure what the effect would be on users at the moment. What are you doing to these supposedly "ordinary" accounts that require them to have either customized permissions or blocked inheritence? >I dont know why the permissions are reset after such a long time, I thought by default they would be re-applied after 1 hour or so. I did check to see if the reg key that can change the default time is set, and it is not preset. Next time, before you make changes to the account, check the time the account was last modified. You might also want to enable auditing t discover who/what is altering membership of groups or altering permission on users. >Man, I hate inheriting an Exchange structure that is a mish-mash of several external people's changes/upgrades/hacks done over a few years. This isn't an Exchange thing. There's something going on in your AD that you don't understand yet. >So, for now if I clear admincount but leave inheritance as is (no inheritance), will the permissions still be reset at some future date I wonder? They will the next time someone monkeys with the account! >I need time to assess whether enabling inheritance will break even more stuff. I'd turn that around and ask why it's disabled (with the knowledge that the only time it should be disabled is if the account is a member of a priviledged group). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Sorting through the output of ldifde to find admincount=1 set on groups. Serveral hundred users (all of them!) are listed as having admincount=1. I have found 1 interesting entry so far: a group called staff, which is a member of another group called installers, which itself is a member of domain admins! The staff group seems to contain almost all domain users (including most but not all of the shared mailbox accounts). I wonder if this staff group is the smoking gun. What a mess! Does this mean that any user on the domain has domain admin privileges. I will have a heart attack if this is the case! I havent been around here long enough to know the history of who created these groups and why, but this is an irregular setup, to say the least.

On Wed, 10 Nov 2010 18:47:51 +0000, eChange wrote: >Sorting through the output of ldifde to find admincount=1 set on groups. It's easier to work with CSVDE when you're looking for stuff. You can suck it into Excel or Access and sort/search a lot easier. >Serveral hundred users (all of them!) are listed as having admincount=1. I have found 1 interesting entry so far: a group called staff, which is a member of another group called installers, which itself is a member of domain admins! > >The staff group seems to contain almost all domain users (including most but not all of the shared mailbox accounts). > >I wonder if this staff group is the smoking gun. > >What a mess! Does this mean that any user on the domain has domain admin privileges. That's the way it looks. >I will have a heart attack if this is the case! Call 911! >I havent been around here long enough to know the history of who created these groups and why, but this is an irregular setup, to say the least. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I just found a solution to something similar today, although it's outlook 2010 and Exchange 2003/2010 mixed at the moment. A shared mailbox (that has appropriate access) was not able to send to a restricted dl. My user was trying to use that mailbox to send out a notification. After looking a little closer - it appeared to be a client issue to me, cause I know it was working before and outlook was showing some kind of "Exchange Account" as the person it was trying to send as, even though they had clearly marked the address that was to be the from: Also, when I created a new profile (under the user's credentials) that was associated with the shared mailbox and not their own personal mailbox, the message was able to be sent. Looked like outlook to me... I ran off to research... So to fix it the user actually went into their Outlook profile (not a new profile) and added the mailbox as a new account. Then outlook would actually try to send as that account to the exchange server. Outlook was confused, trying to say "I'm user xxx, but please set the from field to this in my message." And Exchange said - no - sorry. After adding the mailbox to the account, outlook was smart enough to say "I'm shared mailbox yyy, please set the from field to yyy@domain.com"